Conf. univ. dr. Gabriela MEŞNIŢĂ 


ANALIZA SISTEMELOR 
INFORMAȚIONALE 


Cap. 3 Studierea sistemului existent 
şi determinarea cerinţelor noului sistem 


3.1 Consideraţii generale privind tipurile de sisteme supuse dezvoltării .........mene nene nenea eee 


3.2 Studierea sistemului existent 
3.2.1 Analiza informaţiilor de ieşire obţinute din actualul sistem 
3.2.2 Analiza datelor de intrare 


3.3 Determinarea cerinţelor pentru noul sistem 
3.3.1 Apecte generale privind desfăşurarea activităţii de determinare a cerinţelor 


3.3.3 Tipuri de cerințe ce pot fi identificate în timpul analizei 


3.3.4.2 Caracteristicile specificațiilor de analiză 


Iaşi, 2003 


3.2.3 Analiza modului în care sunt stocate, accesate şi păstrate datele .......... ceea 
3.2.4 Analiza proceselor de prelucrare la care sunt supuse datele............ unea eee 


3.3.2 Surse de identificare a cerinţelor... nenea nenea aaa na ana aaa 
3.3.4 Întocmirea specificaţiilor de analiză ..........cmcenee cena eenenaeneenena caca eneeaeceneeaeceneeneaceneaeneeaeaee 
3.3.4.1 Conţinutul de bază al unei specificaţii... nenea nenea aa na na ana 


ANALIZA SISTEMELOR INFORMAŢIONALE 


In faza de analiză a sistemelor, numită şi analiza funcţională, se urmăreşte obţinerea 
elementelor necesare determinării cerințelor informaţionale care vor sta la baza proiectării 
noului sistem. Această fază trebuie să dea răspunsuri la următoarele întrebări: 


ce se realizează în sistemul existent? 

care sunt intrările, ieşirile şi procesele din sistemul curent? 

care sunt punctele tari şi pot fi păstrate în noul sistem, respectiv punctele slabe şi care 
trebuie înlocuite? 

care sunt cerințele noului sistem? 


De aceea, analiza sistemelor trebuie să urmărească atingerea a trei obiective majore: 


1. 


înțelegerea deplină a sistemului şi a modului său de funcționare; 


2. determinarea cerințelor informaționale ale noului sistem; 


3. 


modelarea conceptuală a sistemului. 


În acest sens, se desfăşoară următoarele activități: 

1. Studierea sistemului existent presupune, în primul rând, identificarea punctelor tari şi slabe 
ale sistemului, respectiv a acelor elemente care au generat apariţia problemelor în sistem, 
activitate realizată printr-o serie de analize orientate spre principalele componente ale 
sistemului informaţional, respectiv: 


ieşirile sistemului; 

datele de intrare în sistem; 

modul de stocare şi păstrare a datelor; 
procesele de prelucrare. 


2. Determinarea cerinţelor informaţionale ale noului sistem 

Activitatea implică identificarea persoanelor care au nevoie de informații, când şi sub ce 
formă. Analiştii trebuie să lucreze şi în cadrul acestei activităţi foarte apropiat cu utilizatorii. 
Cerinţele informaţionale se referă la: 


intrările şi ieșirile în/din sistem (tipul, formatul, conținutul, volumul şi frecvenţa fiecărei 
intrări/ ieşiri, timpul de răspuns); 

prelucrările din sistem (activităţile necesare transformării intrărilor în ieşiri, cum ar fi 
calcule, comparări, reguli); 

stocarea datelor şi controlul în sistem (corectitudinea, exactitatea şi securitatea 
intrărilor, stocării, prelucrărilor şi ieşirilor sistemului) 


Pentru aceste două activităţi analiştii de sistem, respectiv echipa de analiză, au la dispoziție 
o serie de tehnici sau metode, grupate în două mari categorii, respectiv: 


a metodele tradiționale de culegere a informaţiilor 


interviuri individuale; 
anchete realizate prin chestionare; 
intervievarea grupurilor de oameni cu interese comune; 


observarea personalului în momente bine definite pentru a vedea modul în care sunt 
folosite informaţiile pentru exercitarea sarcinilor de serviciu; 


studierea documentației firmei pentru a se cunoaşte conținutul rapoartelor, al politicilor, 
al regulamentelor, precum şi direcțiile spre care se îndreaptă prelucrarea datelor. 


a metode moderne de determinare a cerinţelor sistemului: 


JAD (Joint Application Design) 
RAD (Rapid Application Development) 
prototipizarea. 


3. Modelarea cerinţelor sistemului 
Prin această activitate se urmăreşte crearea unor imagini ale sistemului, prin intermediul 
unor modele, după cum urmează: 
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modelul descompunerii funcționale are ca scop evidențierea principalelor procese, 
subprocese, aplicaţii, proceduri de prelucrare a datelor etc. din cadrul sistemului. De 
fapt, modelul descompunerii funcționale reprezintă, sub formă de diagramă, structura 
ierarhică a componentelor de bază ale sistemului analizat; 

modelul proceselor prin care se evidențiază principalele legături existente între sistemul 
analizat şi celelalte sisteme sau componente organizatorice ale organizaţiei, sau cu 
sisteme externe, precum şi fluxurile principale prin intermediul cărora se stabilesc 
aceste legături. Modelul proceselor este construit prin intermediul diagramelor 
fluxurilor de date, care redau sub formă grafică sursa fiecărui flux de date, procesele de 
prelucrare la care sunt supuse acestea, precum şi destinaţia către care se orientează 
fluxurile de informaţii obținute în urma prelucrărilor. Sursa şi destinația pot fi alte 
sisteme/aplicaţii, persoane, componente organizatorice, parteneri de afaceri, locuri de 
stocare/păstrare a datelor; 

modelul datelor realizat prin intermediul diagramelor entitate-relaţie, reliefează 
obiectele sau lucrurile din lumea reală, sub forma entităţilor de date, şi despre care 
trebuie păstrate date în cadrul sistemului o lungă perioadă de timp. Entităţile de date 
sunt componentele unui sistem care au cea mai lungă perioadă de viaţă şi sunt cele mai 
persistente. 


4. Intocmirea raportului analizei de sistem reprezintă sinteza activităților anterioare şi va 


conține: 


sinteza problemelor existente în sistemul curent şi restricțiile lui; 
cerinţele noului sistem; 

rezultatele modelării conceptuale; 

recomandări privind proiectarea noului sistem. 


3.1 Consideraţii generale privind tipurile de sisteme supuse dezvoltării 


Din perspectiva analizei, fiecare tip de proiect implică surprinderea unor aspecte diferite, 
dar activităţile sunt, în mare parte similare, urmărind desfăşurarea aceloraşi etape şi utilizarea 
unor metode corespunzătoare fiecărei etape. Activităţile sunt diferite în sensul că mediul curent 
de lucru pe care analiştii trebui să-l studieze diferă sub aspectul caracteristicilor de bază. Din 
aceste diferenţe rezultă trei mari categorii ale proiectelor de dezvoltare a sistemelor: 


e sisteme manuale 
e proiecte de informatizare a sistemelor manuale 
e sisteme informatizate supuse modificărilor: 


> rescrierea sistemului 
> îmbunătățirea şi întreținerea sistemului 
> reproiectarea şi redezvoltarea sistemelor 


Diferențele privind analiza în contextul categoriilor de proiecte rezidă în: 


e elementele din sistemul existent supuse analizei; 
e  responsabilitățile analiştilor; 

e rezultatele analizei; 

e factorii care determină dezvoltarea noului sistem. 


In tabelul următor sunt prezentate, în sinteză, aceste caracteristici 


Diferențe privind analiza 
Tipul proiectului | Elementele supuse Responsabilităţi Rezultatele analizei | Factori 
analizei declanşatori 
Modificare - Prelucrările manuale | - Simplificarea - Standarde/ - Întârzieri în 
sistem manual - Fluxurile şi etapele fluxului activităților | proceduri noi prelucrări 
prelucrărilor - Reducerea - Reguli de - Noi forme de 
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Diferențe privind analiza 
Tipul proiectului | Elementele supuse Responsabilităţi Rezultatele analizei | Factori 
analizei declanşatori 
- Rezultatele redundanţelor performanță raportare 
prelucrărilor - Reordonarea - Noi formulare, - Flux greoi al 
prelucrărilor proceduri de control, | documentelor 
- Conţinutul rapoarte - O nouă formă 
formularelor - Noi prelucrări sau organizaţională 
fluxuri 
Informatizare - Modalităţile de - Impactul - Noi formulare - Costurile mari ale 
sistem/comp. înlocuire a componentelor introducere date prelucrării manuale 
prelucrărilor manuale manuale asupra celor | - Conţinutul - Erori în 
- Procesele şi automate fişierelor prelucrarea datelor 
procedurile manuale - Interacțiunea dintre | nomenclatoare şi de | - Creşterea duratei 
comp. informatizate | tranzacții de obținere a 
- Fezabilitatea - Fluxul rapoartelor 
înlocuirii prelucrărilor, mixaj 
procedurilor manuale | procese noi şi 
- Costurile manuale 
informatizării - Noi procese de 
prelucrare 
Rescrierea - Mediul economic - Optimizarea - Modificarea -Îmbunătăţirea 
sistemului - Funcțiile şi fluxului prelucrărilor | structurii fişierelor, prelucrărilor 
procedurile de - Trecerea rapoartelor 
prelucrare programelor într-un - Eliminarea 
nou limbaj eventualelor erori, a 
codurilor neutilizate 
Îmbunătățire/ - Domeniile de lucru - Adăugări de noi - Reproiectarea - Modificări mediul 
Întreţinere ale utilizatorilor; funcționalități; logicii aplicațiilor economic; 
- Legăturile cu alte - Identificare - Modificarea - Solicitări ale 
sisteme; interdependenţe cu structurii BD; utilizatorilor pt. 
- Structura alte aplicaţii ce funcționalitate; 
programelor; folosesc aceeaşi bază - Rafinări solicitate 
de date de utilizatori sau 
“cosmetizare” ale 
sistemului. 
Reproiectare/ - O nouă analiză a - Nevoile şi dorinţele | - Reproiectarea - Migrarea de la o 
Redezvoltare întregului sistem utilizatorilor procedurilor; tehnologie la alte 
- Capcanele ce apar - Conversia bazelor | - Trecerea de la 
odată NTI; de date; prelucrare pe loturi 
- Presiunea - Reintegrarea la online 
conducerii sistemului - Restructurare 
reproiectat în organizaţională 
sistemul firmei. 


3.2 Studierea sistemului existent 


Deşi, este o activitate distinctă în cadrul analizei, ea este foarte asemănătoare, ca tehnică de 
lucru, cu determinarea cerinţelor noului sistem, îşi concentrează atenţia asupra altor obiective, 
respectiv asupra elementelor existente în sistem, în momentul în care s-a inițiat proiectul. 
Activitatea presupune: 

e analiza informațiilor de ieşire obţinute din actualul sistem; 

e analiza datelor de intrare în sistem; 

e analiza modului în care sunt stocate, memorate şi păstrate datele din sistem; 

e analiza proceselor de prelucrare la care sunt supuse datele. 
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Atenţie!!! 


De obicei, studierea sistemului existent apare ca necesară atunci când: 

e este necesară trecerea de la un sistem manual la unul informatizat, 

e nu există nici un fel de documentaţie a sistemului informatizat existent care este supus 
redezvoltării 

e când există destul de multe incertitudini asupra modului în care funcționează sistemul. 


3.2.1 Analiza informaţiilor de ieşire obţinute din actualul sistem 


Principalele informaţii care se obțin în cadrul unui sistem apar sub forma listelor, situațiilor 


de ieşire, documentelor, ecranelor, a răspunsurilor la întrebări, toate încadrate în termenul 
generic de rapoarte. 


Un raport este un document economic în care sunt incluse date predefinite, folosit exclusiv 


pentru a fi citit sau vizualizat. 


Dintre obiectivele prezentării detaliate a ieşirilor obţinute de sistemul existent pot fi 


enumerate: 


determinarea formatului şi conținutului tuturor  listelor/situaţiilor imprimate, ale 
documentelor şi ecranelor furnizate de sistem; 
identificarea momentului de elaborare a rapoartelor (frecvenţa cu care se obțin ieșirile), 
criteriu în funcție de care se pot obține următoarele categorii de rapoarte': 
> rapoarte programate (la termen) — au un conținut predeterminat, formatul lor fiind 
dinainte stabilit; 
> rapoarte neprogramate, cu rol special (rapoarte ad-hoc) — nu au conținutul şi forma 
stabilite, fiind rezultatul unor întrebări puse de către manageri cu privire la o serie de 
probleme de planificare managerială; 
> rapoarte declanşate de excepții — au conținut şi format predeterminat, dar sunt obținute 
numai dacă apar o serie de condiții de excepție în sistemul analizat; 
> rapoarte la cerere — sunt obținute numai ca răspuns la cererea managerilor sau a altor 
angajați, având conținutul şi forma predeterminate. 
determinarea duratei necesare pentru generarea unei ieşiri. 
găsirea răspunsurilor la o serie de întrebări, prin care se determină care este circuitul 
informaţiilor de ieşire la nivelul întregii organizații. Aceste întrebări sunt: 
cine este beneficiarul listei/situației, ecranului sau răspunsului la întrebare? 
ce conţin listele/situațiile, ecranele sau răspunsurile la întrebări? 
când este solicitată obținerea ieşirilor? 
unde sunt transmise listele/situațiile, ecranele sau răspunsurile la întrebări? 
cum sunt utilizate ieșirile? 
câte persoane folosesc sau văd listele/situaţiile, ecranele sau răspunsurile la întrebări? 
verificarea utilității datelor şi informaţiilor conținute de ieşirile sistemului, prin analiza 
următoarelor caracteristici: 
tipul datei (date numerice, alfabetice, imagini, audio, hypertext); 
corectitudinea sau precizia datelor; 
actualitatea datelor; 
orizontul de timp la care fac referire datele (perioade ale activităţilor desfăşurate); 
gradul de sintetizare; 
completitudinea datelor; 
accesibilitatea datelor; 
siguranţa sursei din care sunt obținute datele; 
relevanţa sau valoarea datelor pentru luarea deciziilor. 


VvVYvvYvY 


VYvYvYvvYvvvY 


i Oprea, D. — Analiza şi proiectarea sistemelor informaționale economice, Editura Polirom, laşi, 1999, p. 293 
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urmărirea calităţii ieşirilor, sub aspectul performanţei pe care o obțin cei ce utilizează 
informațiile de ieşiri, calitate urmărită şi prin: 
> introducerea sugestivă (partea de titlu a raportului), care trebuie să fie clară, să scoată în 
evidență numărul raportului şi data întocmirii lui, locurile în care trebuie să fie 
distribuite exemplarele; 
> informaţiile privind instrucțiunile de completare, destinațiile fiecărui exemplar, evitarea 
comentariilor lungi, prin rubrici sugestive; 
> partea principală a raportului, care trebuie să fie echilibrată, cu folosirea corectă a 
spațierilor şi marginilor, etichetarea corectă a rubricilor şi gruparea lor logică, marcarea 
fiecărei rubrici, accentuarea zonelor cheie prin linii sau culori; 
> concluziile (finalul) ieșirii, care trebuie să fie plasate la sfârşitul raportului, să aibă spațiu 
suficient pentru semnături, să prezinte regimul de lucru cu documentul respectiv, să fie 
accentuate totalurile. 


3.2.2 Analiza datelor de intrare 


Activitatea urmăreşte toate aspectele legate de documentele sau informaţiile care sunt 


supuse prelucrării în sistemul existent (intră în sistem). Abordarea acestei activităţi se realizează 
separat, în următoarele două situaţii distincte: 


pentru documentele intrate direct în sistem pe suport de hârtie, când se recurge la 
culegerea datelor conţinute de acestea, de către un operator; 

pentru informaţiile provenite din alte sisteme informaţionale, în special din alte 
aplicaţii, care presupun retratarea lor sub aspectul compatibilităţii cu formatul datelor 
existente în aplicaţia sistemului analizat. 

Din punct de vedere al documentelor, analiza trebuie să reliefeze o serie de aspecte cu 


privire la gradul de optimizare a circuitului lor, momentul în care documentul este emis şi cel al 
prelucrării efective a datelor, precum şi la necesitatea culegerii datelor de pe documente pentru a 
fi supuse prelucrărilor. Astfel, se va pune accent pe următoarele elemente: 


e locul de provenienţă al documentelor (emitentul), urmărind atât locurile din interiorul 
organizației, cât şi cele externe; 

e data emiterii documentului şi data preluării informațiilor în sistem; 

e numărul de exemplare în care se întocmeşte fiecare document; 

e circuitul fiecărui exemplar din document, pentru a depista eventualele locuri în care 
documentul ar putea fi supus aceloraşi sau altor prelucrări; 

e care este frecvenţa de apariţie a documentelor; 

e locul de arhivare a documentelor şi momentul în care intră în acest proces; 

e datele din documente care sunt preluate pentru a fi supuse prelucrării; 

e criteriile de clasificare şi grupare a documentelor; 

e codificările utilizate pentru datele din documente şi cele utilizate în prelucrări; 

e verificările sau controlul la care sunt supuse documentele, din punct de vedere al 
legalităţii, completitudinii şi corectitudinii lor; 

e durata medie a timpului de aşteptare a unui document pentru a fi supus prelucrării, 
precum şi durata medie a prelucrării; 

e dependențele existente între documente pentru a fi supuse proceselor de prelucrare. 


Referitor la intrările care provin din aplicaţiile altor sisteme este necesar să se urmărească: 

e identificarea datelor care intră în sistem din aplicaţiile altor sisteme, electronic sau pe 
suport de hârtie; 

e compatibilitatea structurii datelor; 

e momentele în care sunt necesare datele din alte aplicaţii şi când ele sunt oferite 
sistemului; 
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e identificarea datelor care trebuie să fie supuse unor procese de pregătire (regrupări, 
reordonări sau sortări ale datelor, în funcție de necesitățile sistemului care este supus 
analizei) sau pot fi supuse direct prelucrării. 


3.2.3 Analiza modului în care sunt stocate, accesate şi păstrate datele 


Prin această activitate este necesar să evidenţieze următoarele aspecte: 

e modul de organizare a datelor (fişiere, baze de date), astfel încât să se identifice dacă este 
necesară conversia datelor din formatul fişier în cel specific bazelor de date, sau dintr- 
un format al bazelor de date în altul; 

e definirea atributelor, cu specificarea lungimii, formatului şi tipului; 

e codificarea utilizată pentru entitățile de date; 

e criteriile de stocare şi memorare a datelor; 

e suportul de stocare şi păstrare a datelor (suporţi magnetici, optici, hârtie etc.), descriind 
tipul şi numărul dispozitivelor de stocare aflate pe calculatoarele utilizatorilor; 

e specificarea datelor ce se memorează în locurile de stocare; 

e gradul de normalizare a datelor; 

e frecvența operațiunilor de introducere, restaurare, ştergere, actualizare a datelor; 

e dimensiunea fişierelor sau a bazelor de date (nr. înregistrări, spaţiul de memorie ocupat); 

e timpul necesar pentru obţinerea răspunsurilor din interogarea fişierelor/bazelor de date; 

e identificarea frecvenţei cu care utilizatorii realizează copii de siguranța pentru fişierele 
cu care lucrează, precum şi suportul pe care se păstrează copiile; 

e dacă stațiile de lucru sunt conectate la un LAN sau WAN trebuie să se identifice 
următoarele aspecte: aplicațiile şi fişierele accesibile prin intermediul reţelei; serverul 
sau stațiile unde sunt stocate fişierele utilizatorilor ; ce transferuri de fişiere au loc între 
calculatoarele utilizatorilor, precum şi între acestea şi servere; 

e protecția şi securitatea datelor. 


3.2.4 Analiza proceselor de prelucrare la care sunt supuse datele 


Un proces reprezintă o secvență de proceduri intercondiţionate sau o secvenţă de acţiuni ce 
stau la baza finalizării unei proceduri. Aceste proceduri sunt, adesea, interdependente, având un 
flux bine definit de la o procedură la alta sau de la o acţiune la alta. 

O procedură reprezintă un set de acțiuni organizate pentru a atinge un scop anume (de 
exemplu: culegerea datelor de pe un document, adăugarea unei înregistrări într-o tabelă a unei 
baze de date, interogarea unui baze de date pentru obținerea unei liste, calculul unei valori, 
verificarea dreptului de acces la o informației etc.). 

Distincția dintre o subfuncţie şi o procedură rezultă doar din folosirea termenilor şi mai 
puţin din scopul lor. În general, o procedură este o componentă a unei funcţii generale. Este 
foarte bine structurată şi orientată către acțiuni bine delimitate şi mai puţin orientată către 
control şi gestiune. Funcţiile se gestionează, pe când procedurile sunt executate, deşi această 
diferență este destul de vagă. 

Procedurile sunt orientate spre date, în sensul că sunt declanşate de o tranzacţie sau o 
solicitare de date, fiind componentele active ale unei funcţii. De cele mai multe ori, au caracter 
repetitiv şi uşor de formalizat. 

O funcţie reprezintă un grup de procese şi proceduri executate pentru atingerea unui scop 
predeterminat. Pentru fiecare funcție identificată este necesar să se specifice procesele şi 
procedurile ce trebuie realizate, de una sau mai multe persoane, din unul sau mai multe domenii 
funcționale ale firmei, pentru a sprijini funcția. 

Analiza funcţiilor, proceselor, procedurilor înseamnă descrierea şi definirea proceselor şi 
procedurilor fiecărui utilizator pentru a determina dacă, şi în ce condiţii, pot fi automatizate. 
Analiza funcțională independentă a acestor descrieri nu oferă suficiente elemente privind 
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fluxurile, complexitatea sau interdependența dintre procedurile de prelucrare ale utilizatorilor. 
De asemenea, tratarea individuală a proceselor nu permite identificarea fluxurilor de prelucrare 
şi nici a proceselor care sunt externe utilizatorului, dar între care există intercondiționare. 

În faza de analiză este necesar să se identifice şi să se descrie detaliat următoarele aspecte: 

e toate domeniile unde procesele şi procedurile aflate în legătură sunt executate; 

e ce reprezintă acele procese sau proceduri; 

e cum şi de ce sunt executate; 

e cum fiecare proces sau procedură intră în legătură cu alte procese/proceduri ale aceleiaşi 
funcţii sau cu procesele/procedurilor altor funcții; 

e tranzacţiile economice care declanşează procesul/procedura; 

e pentru fiecare tranzacţie se va descrie documentul sursă, timpul, frecvenţa, volumul, 
toate condițiile de excepție şi orice altă operaţiune care se realizează asupra tranzacţiei; 

e dacă numai o anumită parte a datelor rezidente în documentul-sursă a tranzacţiei este 
necesară, se va specifica de ce nu sunt utilizate celelalte date. De asemenea, trebuie să se 
identifice orice sursă suplimentară a aceloraşi date, ca şi regulile de validare şi verificare 
a lor; 

e pentru fiecare tranzacţie, se va descrie în detaliu prelucrarea care este declanşată ca 
rezultat al apariției ei, dacă prelucrarea se realizează imediat ce a apărut, este amânată 
sau condiționată de alţi factori declanşatori. De asemenea, trebuie să se specifice dacă 
prelucrarea tranzacţiei este dependentă de o prelucrare anterioară sau de disponibilitatea 
unor date deja prelucrate; 

e orice procedură manuală care este aplicată prelucrării tranzacţiei trebuie să fie 
identificată, descrisă şi, dacă este posibil, inclusă într-o procedură informatizată; 

e orice salvare de date dintre paşii prelucrării trebuie identificată (salvare temporară). Vor 
fi descrise metodele de salvare, precum şi datele supuse acestui proces; 

e orice raport generat ca rezultat al prelucrării trebuie să fie documentat, iar un model al 
fiecărei pagini unice inclusă în documentaţia sistemului. De asemenea, trebuie incluse 
controalele şi auditările care stau la baza realizării raportului; 

e verificările, punctele de control, precum şi punctele de decizie trebuie să fie clar 
identificate şi descrise; 

e toate procedurile pentru detectarea erorilor şi corectarea lor, precum şi acțiunile care se 
fac la detectarea erorilor. 


Atenţie!!! 


Identificarea funcţiilor/proceselor/procedurilor unui sistem informatizat (există o aplicație 
care sprijină cea mai mare parte a prelucrărilor din sistem) poate fi văzută ca o analiză a 
meniului aplicaţiei, cu opţiunile şi subopţiunile specifice. 

Atunci când sistemul este manual, trebui urmărit ce fac utilizatorii cu diferitele documente 
pe care le primesc pentru a putea obținte diferite rapoarte/liste/situaţii, cum ar fi transcrierea 
unor câmpuri de pe anumite documente în alte documente, sub forma centralizatoarelor, 
totalizarea anumitor câmpuri, aplicarea anumitor formule de calcul pentru obţinerea şi 


completarea unor câmpuri de pe documentul pe care îl folosesc ş.a.m.d 
x 


x x 


Pe un plan mai general, în urma acestor activități de studiere a sistemului existent, se va 
realiza o documentație privind: 
e modul în care au loc activitățile de culegere, prelucrare, stocare şi transmitere a 
informațiilor; 
e modul de utilizare a echipamentelor, software-ului (dacă este cazul), resurselor umane; 
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e dimensiunile şi natura schimbării, determinate prin analiza punctelor tari şi slabe ale 

sistemului. 

Exemple de puncte slabe: inoportunitatea sau inexactitatea informaţiilor obţinute de sistem, 
organizarea ineficientă a datelor, costuri mari de stocare a datelor, slaba pregătire a personalului în 
utilizarea tehnicii de calcul, proasta organizare a fluxurilor informaționale. 

Pe baza informațiilor obținute din studierea sistemului existent, urmează modelarea lui, cu 
ajutorul diagramelor fluxurilor de date, diagramelor entitate-relație, diagramele stărilor de 
tranziție etc. pentru a crea imaginea grafică a sistemului. Şi această activitate de modelare a 
sistemului existent este obligatorie în situația în care nu există nici o documentaţie, altfel se 
folosesc specificaţiile existente. 

Modelarea va fi prezentată în capitolele viitoare. 


3.3 Determinarea cerinţelor pentru noul sistem 


O cerinţă reprezintă o funcţie sau o caracteristică a unui sistem care este necesară, respectiv 
un comportament cuantificabil şi verificabil pe care un sistem trebuie să-l aibă, precum şi 
restricțiile sub influența cărora sistemul trebuie să lucreze pentru a răspunde obiectivelor unei 
organizații şi pentru a rezolva un set de probleme. 

Cerinţa mai poate fi văzută şi din următoarea perspectivă”: 

1. condiția sau abilitatea necesară unui utilizator pentru a rezolva o problemă sau pentru a 

atinge un obiectiv; 

2. condiția sau capacitatea pe care trebuie să o deţină un sistem sau o componentă a 
sistemului pentru a satisface un contract, un standard, o specificaţie sau alt document 
impus; 

3. reprezentarea documentată a unei condiţii sau capacități/abilități, aşa cum a fost 
definită la punctele 1 şi 2. 

Activitatea de determinare a cerinţelor este considerată una din cele mai dificile din 
faza de analiză, datorită greutății de evaluare cu exactitate a necesarului de informaţii. În 
unele situaţii, utilizatorii pot fi subiectivi când sunt abordaţi pe o astfel de temă, iar în alte 
situații nu ştiu de ce informaţii au nevoie sau pot să le identifice în mod eronat. 

La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii 
sistemului curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor primare, 
a rapoartelor, a procedurilor folosite. 

Cauzele care determină problemele de culegere a cerinţelor sunt grupate astfel: 

e cauze legate de scop — granițele sistemului sunt greşit stabilite sau utilizatorii/ 
beneficiarii sistemului specifică detalii tehnice inutile care mai mult derutează decât să 
clarifice obiectivele sistemului; 

e cauze privind imposibilitatea de a înțelege dorinţele utilizatorilor, pentru că: 

nu sunt foarte siguri asupra elementelor de care au nevoie; 

nu cunosc îndeajuns de bine performanţele şi limitele mediului lor de lucru; 

nu înţeleg în totalitate domeniul problemei; 

au probleme în comunicarea nevoilor; 

omit informaţii pe care ei le consideră “implicite”, “normale”; 

cerințele specificate pot intra în conflict cu nevoile altor utilizatori; 

echipa de analiză foloseşte un limbaj tehnic, greu de perceput de către utilizatori; 

specifică cerinţe ambiguu formulate sau sunt netestabile. 

e cauze legate de volatilitatea informaţiilor. Cerinţele, de cele mai multe ori, se modifică 
în timp. 

Prin determinarea şi analiza cerințelor se urmăreşte: 


VYvYvvvYvvY 


2 Christel, M., Kang, K.C. — Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-012, ESC-TR--92-012, 
1992, p. 2 
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e gruparea şi organizarea acestora în subseturi relaționate în funcție de 
caracteristicile lor comune sau problema pe care o rezolvă, 

e identificarea relațiilor dintre o cerinţă cu altele, 

e examinarea cerinţelor în ceea ce priveşte consistenţa datelor, eventualele omisiuni 
sau ambiguităţi, 

e  ierarhizarea cerinţelor în funcţie de nevoile utilizatorilor. 

Din momentul în care analiza cerinţelor începe este necesar să se examineze următoarele 

aspecte: 

e dacă au fost specificate toate cerinţele la un nivel corespunzător de abstractizare. Cu alte 
cuvinte, dacă unele cerințe indică un nivel de detaliere tehnică necorespunzătoare 
acestei etape; 

e fiecare cerință este cu adevărat necesară sau reprezintă o caracteristică sau un element 

suplimentar ce nu este esenţial pentru scopul sistemului; 

fiecare cerinţă este bine delimitată şi nu este ambiguă; 

fiecare cerinţă are identificată o sursă (în general, o anumită persoană); 

să nu intre în conflict unele cerinţe cu altele; 

să fie asigurată satisfacerea cerinței prin aplicaţia informatică care urmează să fie 
dezvoltată; 

e fiecare cerință să poată fi testată în momentul în care urmează să fie implementată; 


3.3.1 Apecte generale privind desfăşurarea activităţii de determinare 
a cerinţelor 


Analiza cerințelor poate fi împărțită în patru domenii de activitate, şi anume: 
e identificarea problemei; 

evaluarea şi descrierea soluţiilor de rezolvare a problemei; 

elaborarea specificaţiilor de analiză; 

e revizuirea cerinţelor. 

Inițial, analistul studiază specificațiile sistemului existent şi planul proiectelor aflate în curs 
de realizare pentru dezvoltarea sistemului la nivel de organizație. Este foarte important să se 
înțeleagă sistemul într-un context general şi să se revizuiască scopul sistemului care a stat la 
baza planificării inițiale a proiectului. Apoi este necesar să se realizeze un proces amplu de 
comunicare cu utilizatorii astfel încât să se asigure suportul real pentru înțelegerea problemei. 
Scopul este de a identifica elementele de bază ale problemei aşa cum sunt percepute de 
utilizatori. 

Evaluarea şi descrierea soluțiilor reprezintă un important pas în continuarea eforturilor de 
determinare a cerințelor. Analistul trebuie: 

e să definească toate datele externe despre obiectele observabile din sistem la o analiză 

sumară a acestuia; 

e să evalueze fluxurile şi conţinutul informațional al acestora; 

e să definească şi să descrie toate funcţiile sistemului; 

e să înțeleagă comportamentul sistemului în contextul evenimentelor şi fenomenelor 

economice care îl afectează; 

e să stabilească caracteristicile interfețelor şi a dialogurilor cu utilizatorii, fără a surprinde 

detaliile şi restricțiile de proiectare. 

Fiecare dintre aceste sarcini servesc la descrierea sistemului astfel încât să se abordeze, într- 
o manieră generală, modul de dezvoltare a sistemului sau să se documenteze o soluţie. 

După ce problemele au fost identificate, analistul determină ce informaţii trebuie să se 
obţină din noul sistem şi ce date trebuie culese şi prelucrate în cadrul acestuia. 

În timpul evaluării problemelor curente şi a informaţiilor specifice noului sistem (date de 
intrare şi ieşiri), analistul începe să identifice una sau mai multe soluţii. De aceea este necesar ca 
încă de la început să se definească în mod detaliat componentele, funcțiile de prelucrare şi 
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comportamentul sistemului. Când toate aceste elemente au fost stabilite, se iau în considerare 
arhitecturile de bază pentru implementarea noului sistem. 

Procesul de evaluare şi descriere a soluţiilor continuă (nu l-a nesfârşit!!!!) până când atât 
analistul, cât şi utilizatorii ajung să vadă în aceeaşi manieră noul sistem, astfel încât acesta să 
poată fi descris (documentat) în mod corespunzător pentru următorii paşi de dezvoltare 
(proiectare, implementare). 

Atenţie!!! 
Prin evaluarea şi descrierea soluţiei de dezvoltare a noului sistem, principalul efort al 
analistului se orientează spre “ce” va face sistemul şi nu spre “cum” va face: 
e Ce date trebuie să obțină sistemul şi ce date trebuie să folosească? 
e Care sunt funcţiile de prelucrare pe care trebuie să le efectueze sistemul? 
e Ce comportamente trebuie să apară la nivelul sistemului? 
e Ce interfeţe trebuie să fie definite şi ce restricţii (reguli) se aplică? 

În timpul evaluării şi descrierii soluţiei, analistul creează modele ale sistemului pentru a 
înțelege mai bine fluxul datelor, prelucrările funcționale, comportamentul operaţional şi 
conţinutul informaţional (al intrărilor şi ieşirilor). Modelele servesc ca suport pentru proiectarea 
şi crearea specificaţiilor sistemului. 


3.3.2 Surse de identificare a cerinţelor 


Analiza cerinţelor se concretizează în diferite forme ale informaţiilor colectate, cum ar fi”: 
1. Informaţii obținute în urma conversaţiilor cu utilizatorii sau prin observarea activităților 
prestate de aceştia: 
e copii sau sinteze ale interviurilor; 
e răspunsuri la chestionare sau interpretări ale acestora; 
e însemnări şi rezultate din observarea activităţilor; 
e procese verbale ale şedinţelor ce au avut loc în acest scop. 
2. Informaţii scrise care există în unitate: 
e declaraţii ale misiunii şi strategiei firmei; 
e exemplare ale formularelor, rapoartelor şi machetelor de ecrane; 
e manuale ale procedurilor; 
e descrieri ale posturilor de lucru; 
e manuale de instruire; 
e scheme de sistem; 
e documentaţia sistemului existent; 
e rapoartele consultanţilor etc. 
3. Informaţii obținute cu ajutorul calculatorului: 
e rezultate ale sesiunilor JAD; 
e copii ale fişierelor sesiunilor grupului de sprijinire a sistemului; 
e conţinutul depozitelor şi rapoartele existente în CASE; 
e ecrane şi rapoarte rezultate din prototipurile sistemului ş.a. 
Odată cu procesul de culegere a informaţiilor prezentate, analistul trebuie să afle şi alte 
aspecte despre organizație, cum ar fi: 
e obiectivele firmei, pentru a se vedea modul în care sunt derulate activitățile ei; 
e informaţiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le 
revin; 
e datele (descrierea lor, volumul, mărimea, periodicitatea ş.a.) vehiculate în unitate pentru 
fiecare loc de muncă; 


3 Hoffer, J.A., George, J.F., Valacich, J.S. — Modern Systems Analysis and Design, The Benjamin/Cummings Publishing 
Company, Inc., Sand hill Road, Menlo Park, CA, USA, 1998 
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când, cum, de către cine şi ce date circulă, se transformă sau se înregistrează; 

ordinea de prelucrare şi dependența dintre datele trecute prin diverse activităţi 
desfăşurate; 

regulile prin care se specifică modul în care sunt transmise şi prelucrate datele; 

politicile şi orientările care descriu modul în care se desfăşoară activitatea unităţii, 
ținându-se cont de mediul şi piaţa în care funcționează; 

evenimentele marcante şi momentele declanşării lor, prin care se schimbă valoarea 
datelor. 


3.3.3 Tipuri de cerinţe ce pot fi identificate în timpul analizei 


În timpul analizei, cerințele pot fi grupate în patru mari categorii, în funcţie de percepția pe 
care o au utilizatorii asupra celor prezentate de analist, şi anume“: 


cerințe normale (esenţiale), prezentate de analist în timpul întâlnirilor cu utilizatorii şi 
care sunt considerate ca fiind obişnuite pentru un sistem care se dezvoltă. Exemple de 
astfel de cerințe se referă la tipurile şi formatele de ecrane pentru culegerea datelor, 
prezentarea funcțiilor de prelucrare specifice noului sistem, descrierea performanțelor 
pe care le poate asigura noul sistem; 

cerinţe obligatorii din punct de vedere al utilizatorilor, considerate implicite pentru un 
sistem, motiv pentru care utilizatorii nici nu mai consideră ca fiind necesară prezentarea 
lor atunci când sunt întrebaţi care ar fi nevoile lor. Însă nedefinirea lor în timpul 
întâlnirilor cu analistul poate determina o puternică nemulțumire. Exemple de astfel de 
cerințe ar putea fi descrierea interfețelor-utilizator, corectitudinea şi siguranța 
operațională, instalarea uşoară a aplicaţiilor; 

cerințe “surpriză”, care vin în întâmpinarea aşteptărilor utilizatorilor şi oferă o mare 
satisfacție atunci când sunt prezentate de către analist. Exemplu: posibilitatea de a avea 
la dispoziţie utilitare incluse în aplicaţia nouă, care în mod normal sunt specifice soft- 
urilor de bază, disponibilitatea sistemului astfel încât utilizatorul să-şi poată configura 
propriile rapoarte pe baza instrucțiunilor clar definite în cadrul aplicației. 

cerințe dorite de utilizatori, care sunt de multe ori formulate ambiguu, în contradicție cu 
cerinţele altor utilizatori sau cu scopul sistemului sau se regăsesc sub o formă sau alta în 
celelalte cerinţe. 


În urma desfăşurării activităţilor specifice culegerii cerinţelor, cu ajutorul diferitelor 
metode, activități care se desfăşoară, de multe ori, odată cu studierea sistemului, se pot 
desprinde următoarele mari categorii de cerințe, ce urmează a fi luate în considerare în 
următoarele faze de dezvoltare a sistemului“: 


cerințe funcţionale în care sunt incluse acele necesități de modificare a unor funcții 
existente sau de dezvoltare a unor noi funcționalități. Cerinţele funcționale sunt oferite, de 
cele mai multe ori, de către utilizatorii finali ai sistemului. Dintre aceste cerințe pot fi 
enumerate: 


e cerinţe de modificare a circuitului informațional, în sensul eliminării sau adăugării de noi 


fluxuri informaţionale, în funcție de nevoile reale ale utilizatorilor şi de nevoile de 
prelucrare ale sistemului; 


4 Oprea, D. — Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom, laşi, 1999, p. 278 
Pressman, R.S. — Software Engineering. A Practioner 's Approach. European Adaptation, Fifth Edition, McGraw Hill, London, 


2000, pp. 273-274 


5 Lauesen, S. — Software Requirements. Styles and Techniques, Samfundslitteratur, 1999, p. 1-1, www.itu.dk/slauesen/Papers 


(accesat pe 23/10/2002) 

System Development Center — SDC Guidline: Software Requirements Engineering and Management, Science Applications 
International Corporation, Falls Church, VA 22042, 2000, pp. 3-5. 

Right Track Associates, Inc.-A Process for Project Requirements, www.ittoolkit.com-cgi-bin-itmember (accesat pe 
10/09/2002) 


Cap.3 — 12 


STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINȚELOR NOULUI SISTEM 


e cerinţe de schimbare a anumitor proceduri de prelucrare, prin adăugarea sau eliminarea 
unor procese de prelucrare, plecând de la cerinţele de informare ale utilizatorilor sau de 
integrare cu alte sisteme; 

2. cerinţe nonfuncţionale sau tehnice, prin care sunt urmărite mai multe aspecte tehnice ale 
noului sistem, cerinţe care, într-o anumită măsură, se determină de către analist plecând de la 
cerințele funcționale formulate de către utilizatorii sistemului. Cerinţele nonfuncționale 
specifică proprietățile sistemului, cum ar fi restricțiile de mediu şi implementare, 
performanța, dependența de o anumită platformă de dezvoltare, mentenabilitatea, 
extensibilitatea şi siguranța. Cerinţele tehnice sunt formulate de echipa tehnică de dezvoltare 
a proiectului. Dintre cerinţele nonfuncționale specifice unui sistem pot fi enumerate: 

e disponibilitatea datelor; 

e viteza şi timpul de răspuns pentru obținerea unei informaţii; 

e modul de organizare şi stocare a datelor; 

e calitatea informaţiilor de ieşire, din punct de vedere al momentului obținerii lor, al 
formei de prezentare şi al modului de transmitere; 

e introducerea unor tehnologii informaţionale noi pentru organizație, cum ar fi înlocuirea 
sistemului de prelucrare de tip file/server cu arhitectura client/cerver, trecerea la 
prelucrările de date bazate pe tehnologia orientată-obiect, implementarea unei soluții 
EDI ş.a. 

3. cerinţe privind derularea proiectului de dezvoltare a sistemului, pentru a determina 
nevoile generale ale proiectului (resurse, plan al comunicărilor, relația cu beneficiarii 
sistemului etc), gestiunea modalităţilor în care proiectul poate fi coordonat, inclusiv 
politicile, procedurile şi practicile cele mai bune pentru gestiunea proiectului. Astfel de 
cerinţe sunt furnizate de către echipa IT a proiectului de dezvoltare.; 

4. cerinţe economice pentru a identifica scopul şi viziunea generală a proiectului, inclusiv 
scopul, obiectivele firmei, cerințele privind creşterea eficienţei activităților acoperite prin 
sistemul dezvoltat, rata de recuperare a investiţiei şi veniturile pe care le generează. 
Cerinţele economice sunt formulate de către utilizatorii finali şi conducerea firmei. 


3.3.4 Întocmirea specificaţiilor de analiză 


Produsul final al activității de analiză îl reprezintă specificaţia de analiză sau specificaţia 
cerințelor, care reprezintă o transpunere într-un document, cu o formă aproape standardizată, 
a rezultatelor obținute în această fază. Scopul său îl constituie comunicarea rezultatelor celor 
interesați, servind şi ca reper pentru etapele următoarele, respectiv pentru etapa de proiectare. 


Atenţie!!! 


Una din cele mai mari dificultăţi în dezvoltarea sistemelor o constituie lipsa 
specificaţiilor de analiză, ceea ce determină, de multe ori, obţinerea unor sisteme proiectate 
superficial, care nu răspund cerinţelor celor care le vor folosi, greu de întreţinut şi actualizat. 

Lipsa specificaţiilor de analiză poate determina renunţarea la dezvoltarea unei aplicații, 
plecând de la neînțelegerile care se ivesc între utilizatori şi echipa de proiectare şi implementare. 

În plus, specificaţiile de analiză pot fi văzute şi ca un document cu caracter contractual 
între utilizatorii/beneficiarii sistemului şi echipa/firma care dezvoltă sistemul/aplicația. 


Ca urmare, o descriere foarte precisă este preferată de cele mai multe ori, dar trebuie să se 
țină cont de faptul că specificaţia trebuie să fie uşor de înţeles şi de către utilizatorii sistemului, 
ceea ce înseamnă utilizarea unui limbaj natural şi a imaginilor uşor de perceput şi înțeles. Pentru 
utilizatori, specificaţia reprezintă o descriere clară şi precisă a funcționalităţii pe care sistemul o 
oferă, iar pentru proiectanți, punctul de start al etapei de proiectare. 
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Utilizatorii sunt mulțumiți dacă li se oferă un document care “vorbeşte pe limba lor”, limbaj 
care este folosit în domeniul lor de activitate. Proiectanţii, pe de altă parte, solicită un limbaj 
care apelează la concepte utilizate în zone lor de specialitate. 

În practică, se ajunge de multe ori la un compromis sau pot fi prezentate forme diferite ale 
specificațiilor în funcţie de cei cărora li se adresează. 


3.3.4.1 Conţinutul de bază al unei specificaţii 


Specificaţiile de analiză ar trebui să conţină: 


componenta introductivă în care se regăsesc scopul şi obiectivele sistemului; 
componenta descriptivă oferă prezentarea analitică a problemei pe care sistemul 
trebuie să o rezolve. Conţinutul informaţional, fluxurile şi structura lor trebuie să fie 
documentate. De asemenea, trebuie descrise interfețele (legăturile) cu elementele 
externe sistemului, precum şi pentru funcțiile specifice lui (componentele interne); 
componenta funcțională în care sunt prezentate detaliile privind fiecare funcţie a 
sistemului, restricțiile de proiectare, caracteristicile de performanţă, una sau mai multe 
diagrame pentru reprezentarea grafică a structurii generale a sistemului şi a 
legăturilor dintre funcțiile sistemului cu alte sisteme; 

reprezentarea comportamentului sistemului, respectiv a modului de execuţie a 
proceselor ca urmare unor evenimente externe şi a caracteristicile de control intern 
criteriile corespunzătoare de validare a cerinţelor. Criteriile de validare reprezintă 
poate cea mai importantă parte şi, de cele mai multe ori, cea mai neglijată. Cum se 
poate recunoaşte că implementarea unui sistem va reuşită? Ce clase de teste trebuie să 
fie identificate pentru validarea funcțiilor, performanţelor şi restricțiilor sistemului?. 
Această parte este neglijată deoarece pentru completarea ei este necesar să se înțeleagă 
cerințele sistemului, greu de realizat în această etapă. De aceea, specificarea criteriilor 
de validare acționează ca o revizuire implicită a tuturor cerințelor; 

orice alte informaţii necesare cu privire la cerințele identificate, printre care o 
bibliografie şi un index al termenilor utilizați. 


Atenţie!!! 


Specificațiile de analiză nu conțin numai documentaţia descriptivă a sistemului, ci şi 
modelul sistemului, sub forma diagramelor fluxurilor de date, diagramelor entitate-relaţie, 
diagramelor de redare a stărilor de tranziţie ale proceselor. 


3.3.4.2 Caracteristicile specificaţiilor de analiză 


O cale sigură de a asigura că specificația de analiză ce rezultă din această etapă este de a 
urmări ca toate cerinţele din acest raport au o serie de caracteristici, dintre care cele mai 
importante sunt: 


gradul de testare şi verificare. Dacă o cerință nu poate fi testată sau verificată în mod 
efectiv la finalizarea sistemului la un cost rezonabil, atunci gradul în care această cerință 
a fost atinsă sau nu poate fi determinat. În principiu, cerinţele sistemului trebuie să fie 
descrise astfel încât să constituie un criteriu de acceptare a noului sistem. Un element 
cheie pentru testarea şi verificarea unei cerinţe constă în prezenţa unor parametri ce pot 
fi măsuraţi efectiv şi exact. 

Exemple de cerinţe testabile şi netestabile: 


Cerinţe testabile Cerinţe netestabile 
Determinarea valorii unui produs vândut prin Valoarea unui produs vândut reprezintă costul total 
înmulțirea cantităţii cu prețul unitar pentru fiecare articol comandat. 


Cantitatea de produse care trebuie comandate Cantitatea de produse care trebuie comandate 
periodic se determină prin înmulţirea mediei periodic ar trebuie să fie egală cu o aprovizionare 
vânzărilor zilnice cu 30. la 30 de zile. 
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Stocurile zilnice trebuie să fie determinate exact Stocurile zilnice trebuie să fie determinate cu un 
la sfârşitul fiecărei zile. grad de acuratețe de + 2% pentru cel puţin 99% din 
produsele existente în stoc. 


e justificarea, exactitatea şi nivelul de corectitudine. Probabil nici n-ar mai trebui 
specificat că toare cerinţele trebuie să reflecte exact nevoile utilizatorilor finali, Totuşi, 
prea des, conştient sau nu, caracteristici sau funcții ale sistemelor care nu sunt necesare 
se regăsesc în specificațiile de analiză a sistemului. Deşi cererile şi dorinţele unui grup 
mic de utilizatori par a fi bune, ele pot să nu determine adăugarea de funcții 
semnificative pentru sistem, dar pot implica o creştere importantă a costurilor de 
dezvoltare. Este destul de important să se asigure că toate cerințele identificate sunt 
cerinţe reale ale sistemului şi nu ceva care ar fi drăguţ să se regăsească în sistem. Dacă 
necesitatea apariției unei cerințe nu poate fi justificată cu argumente reale, atunci, cel 
mai probabil, ea nu este necesară; 

e fără ambiguitate. Una din cele mai importante caracteristici ale unei cerinţe bune o 
constituie formularea ei cât mai clară, fără ambiguități, adică trebuie specificată într-o 
manieră detaliată încât să nu existe mai mult de o singură interpretare. 

Exemplu incorect: 

Rapoartele privind vânzările trebuie să fie transmise prin poştă la sfârşitul fiecărei 
săptămâni. 

Deşi, la prima vedere, această cerință pare a fi formulată destul de clar, ea are destul 
de multe aspecte interpretabile. În primul rând, transmiterea prin poştă a rapoartelor 
privind vânzările este chiar o cerință? Chiar în condiţiile în care ar fi cerinţă, orice altă 
formă de transmitere, e-mail, fax, chiar verbal, este considerată inacceptabilă? Unde ar 
trebui să fie transmise rapoartele? Dacă raportul privind vânzările este obținut înainte de 
sfârşitul săptămânii, atunci el trebuie păstrat până atunci? În plus, ce înseamnă exact 
“sfârşitul săptămânii”: vineri dimineaţă, sâmbătă dimineaţă sau la prima oră luni 
dimineaţă? 

Deşi este un pic exagerat, acest exemplu ilustrează importanța furnizării unei cerinţe 
cât mai clare, într-o manieră care să nu conducă la ambiguități. 

Exemplu corect: 

Toate rapoartele privind vânzările emise în cursul săptămânii trebuie să fie transmise la 
sediul central nu mai târziu de ora 16 în ultima zi lucrătoare din săptămână. 

e compatibilitatea. Toate cerințele ar trebuie să fie formulate astfel încât să existe 
compatibilitate cu celelalte cerințe, pentru a nu intra în conflict unele cu altele. Datorită 
creşterii complexităţii sistemelor informatice, această caracteristică este cel mai dificil 
de atins. 

Exemplu: 

Sistemul trebuie să fie capabil să genereze şi transmită toate rapoartele la cerere privind 
vânzările într-o oră din momentul formulării cererii. 

Există vreo diferenţă între semnificaţia rapoartelor privind vânzările şi rapoartele la 
cerere privind vânzările ? Dacă da, atunci cele două cerinţe intră în conflict şi trebuie 
reformulate. 

e nivelul de înțelegere şi posibilitatea modificării. Unul din obiectivele esențiale ale 
specificației de analiză este de a permite comunicarea cerințelor sistemului tuturor 
persoanelor interesate de sistem (utilizatori, beneficiari), nu numai analiştilor şi 
programatorilor. Ca urmare, nu toţi cei care citesc specificaţiile deţin cunoştinţe tehnice. 
Pentru a răspunde tuturor celor care vor citi specificaţia, toate cerinţele ar trebui să fie 
scrise astfel încât să fie înţelese atât de specialiştii în sistemele informaţionale, cât şi de 
cei care nu fac parte din această categorie. În plus, având în vedere perioada destul mare 
solicitată de procesul de analiză a unui sistem complex, cerinţele trebuie să fie scrise 
astfel încât să poată fi modificate pentru a surprinde modificările de la nivelul 
proceselor economice sau a mediului de afaceri. Formularea rigidă şi codificarea 
cerințelor poate influenţa, uneori, negativ dezvoltarea sistemului. 
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Exemplu de fomulare a cerinţe clare: 

Sistemul de gestiune a vânzărilor trebuie să sprijine returnarea produselor nedesfăcute, 
nefolosite sau defecte în termen de 14 zile de la data cumpărării. Pe baza chitanţei valabile, 
returnările trebuie să fie acceptate de orice magazin. Fără o chitanţă valabilă, returnările 
trebuie să fie acceptate numai de magazinul unde a fost vândut produsul, după care se verifică 
dacă există în sistem o înregistrare privind vânzarea efectuată acelui client, iar clientul prezintă 
un document de identificare. Orice manager al magazinului poate trece peste aceste reguli şi să 
accepte o returnare. 

Din cerința identificată, analistul ar trebui să evidenţieze condițiile în care o returnare 
este valabilă sau nu. 
posibilitatea de identificare şi urmărire ierarhică. Ultima caracteristică a specificaţiei 
de analiză constă în faptul că fiecare cerință trebuie să fie posibil de urmărit şi 
identificat la un nivel superior, adică cerinţele trebuie să fie structurate într-o anumită 
ierarhie. Identificarea şi urmărirea cerinţelor pot fi obținute prin scrierea fiecărei cerinţe 
a sistemului astfel încât să definească un singur atribut (funcție, proces, regulă etc) al 
sistemului. 

Exemplu 1: 

Sistemul de gestiune a producției colectează automat datele la fiecare oră de pe fiecare linie 
de producție şi le utilizează pentru a actualiza manual datele privind stocurilor. 
Exemplu 2: 

1. Sistemul de gestiune a producției colectează automat la fiecare oră datele de pe fiecare 

linie de producție. 

2. La fiecare oră datele colectate sunt folosite pentru actualizarea manuală a datelor privind 

stocurile. 


În aceste exemple, este destul de evident că pentru colectarea automată a datelor este 
executat un proces, în timp ce actualizarea manuală a stocurilor este efectuată prin 
intermediul unui al doilea proces. Plecând de la exemplul 1, se poate constata că orice 
eroare fie din colectarea datelor, fie din actualizarea stocurilor poate fi rezultatul 
oricărui proces şi este destul de dificil de identificat unde s-a produs eroarea. În cazul 
exemplului 2, dacă procesul de colectare automată a datelor este incorect, atunci prima 
cerință nu a fost îndeplinită, iar problemele sunt strict legate de acel proces. Dacă, pe de 
altă parte, colectarea automată a datelor este corectă, atunci prima cerință este 
satisfăcută, iar problemele apărute rezultă clar din a doua cerință. 

Atunci când cerinţele sistemului sunt identificabile şi posibil de urmărit, testele care 
se efectuează asupra lor pot fi divizate pentru fiecare cerință în parte, determinând 
identificarea şi rezolvarea problemelor într-o manieră mult mai uşoară. 
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